home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group97a.txt
/
000054_icon-group-sender _Fri Feb 28 12:23:11 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
4KB
Received: by cheltenham.cs.arizona.edu; Fri, 28 Feb 1997 12:48:34 MST
Message-Id: <199702281720.AA15519@optima.cs.arizona.edu>
X-Sender: lindsay@mail.rmc.ca
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Feb 1997 12:23:11 -0500
To: icon-group@cs.arizona.edu
From: "John H. Lindsay" <lindsay_j@rmc.ca>
Subject: Re: Icon and two-dimensional matching
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
Content-Length: 3767
At 08:17 1997 02 26 -0500, you wrote:
>[LONG post warning!]
>
>One of the things that strikes me from the partial set of responses
>I've gotten regarding my queries "What's the largest Icon program
>you've written?" and related, is the extent to which these reported
>uses of Icon are examples of "new wines in old bottles". That is to
>say, the applications remain pretty traditional, although Icon brings
>its own means and methods to these problems.
... big snip ...
You (and at least one other poster) rightly point out the nicities and
problems related to 2-dimensional extensions. In the same vein,
I'll drop back to 1-dimensional ideas.
It has bothered me for a long time that the idea of _string_ has
only been applied to single characters in icon and many other
languages. The problems of macro call recognition, local
syntax processing and partial pre-compilation are related to
handling strings of strings or strings of tokens (where a token is,
roughly, a structure consisting of a string with some extra
information). HMP (High-Level Multipurpose Language or High-
Level Macro Language - I.B.M.'s never-openly distributed macro
extension to PL/I) and ML/I (Brown's Macro Language/ I) allow for
recognition of essentially BNF-like patterns of such strings, but
not of string handling with similar operations to what we now use
freely with character strings, only restricted references to the
individual character string RESULTS (from tokens) of recognizing
such token strings. No language seems to support directly or
even to support via a standard library or module, the
character-string-like or tree-like operations on strings of anything
else. (I haven't yet gotten around to looking at TXL - Tree
Transformation Language - done just a few years ago at Queen's
University though, so I shouldn't say that quite yet.) In the string
operations, I'm thinking not only of concatenation and extracting a
copy of a substring, but of Icon and SNOBOL4-like pattern matching
with excursions into other code in the process a la unevaluated
expressions in SNOBOL4 pattern matching and extracting a copy
of or even a reference to (as a pseudovariable) of a matched
portion.
The worst part is that, currently, Icon lacks anything like SNOBOL4's
OPSYN that can be used to give unused unary prefix or binary infix
operators a meaning or a new meaning. Fortunately, with
SNOBOL's polymorphic data, the ability to overload operators
is implicit and it would be implicit in Icon too if Icon had an
OPSYN-like facility.
I would like to play with such ideas, and on more than just pencil
and paper. The dodge of using functions works, but is not as
systactically simple or as expressive as using operators; hence,
it's harder to see underlying structure and problems.
For this type of end, I'd love to see the ability in Icon to create new
operators, and to extend and to redefine existing operators. Even
though Icon has very many pre-defined operators, Individual
problems need more operators, and it seems to me that the lexical
rule for 'what's an operator' is simple. I'd hope that the facility would
generalize the idea of prefix vs postfix for unary operators with the
idea of 2-operator and n-operator binary and n-ary expressions;
such things seem to occur easily in natural language expressions.
The scope of such extensions could be open to discussion, but
with record type definitons being global to a program, global scope
might be appropriate. I wouldn't mind having to code parentheses
to resolve ambiguities for this sort of thing.
All the best !
John H. Lindsay,
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
ROYAL MILITARY COLLEGE OF CANADA
PO BOX 17000 STN FORCES
KINGSTON ON K7K7B4